home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9703 / 000104_owner-urn-ietf _Mon Mar 31 14:29:54 1997.msg < prev   
Internet Message Format  |  1997-04-01  |  4KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id OAA28649
  3.     for urn-ietf-out; Mon, 31 Mar 1997 14:29:54 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id OAA28644
  6.     for <urn-ietf@services.bunyip.com>; Mon, 31 Mar 1997 14:29:52 -0500 (EST)
  7. Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA01792  (mail destined for urn-ietf@services.bunyip.com); Mon, 31 Mar 97 14:29:49 -0500
  9. Message-Id: <9703311929.AA01792@mocha.bunyip.com>
  10. Received: by privateer.windrose.omaha.ne.us; Mon Mar 31 13:30 CST 1997
  11. From: "Ryan Moats" <jayhawk@ds.internic.net>
  12. To: "Dan Connolly" <connolly@w3.org>,
  13.         "Daniel LaLiberte" <liberte@ncsa.uiuc.edu>
  14. Cc: "urn-ietf@bunyip.com" <urn-ietf@bunyip.com>
  15. Date: Mon, 31 Mar 97 13:32:55 
  16. Priority: Normal
  17. X-Mailer: PMMail 1.91 For OS/2
  18. Mime-Version: 1.0
  19. Content-Type: text/plain; charset="us-ascii"
  20. Content-Transfer-Encoding: 7bit
  21. Subject: Re: [URN] urn: prefix is a brand name?
  22. Sender: owner-urn-ietf@Bunyip.Com
  23. Precedence: bulk
  24. Reply-To: "Ryan Moats" <jayhawk@ds.internic.net>
  25. Errors-To: owner-urn-ietf@Bunyip.Com
  26.  
  27. On Sun, 30 Mar 1997 13:27:37 -0600 (CST), Daniel LaLiberte wrote:
  28.  
  29. >Dan Connolly writes:
  30. > > I found another one of the motivations for the urn: prefix,
  31. > > (thanks for the pointer to the WAIS archive!)
  32. > > and it worries me more than any of the other so far:
  33. > > 
  34. > > On Tue, 05 Nov 1996 23:16:17 -0500, Keith Moore wrote:
  35. > > >This is why URNs need a URN: prefix -- because a lot of the value in
  36. > > >having a URN name space with those properties is so *humans* can
  37. > > >recognize a URN when they see it.
  38. >
  39. >We got to that point after my persistent (ha!) arguments that "urn:"
  40. >doesn't mean much else.  Not everyone agrees with Keith on this point,
  41. >of course.
  42. >
  43. >Ironically, Keith and others also argue for semantically meaningless
  44. >numeric URNs and a higher layer of human friendly identifiers, so humans
  45. >will hopefully never see the "urn:" prefix.
  46.  
  47. I have a little free time to devote to this, although I do have the gripe that
  48. WG last call on this (urn syntax) has already passed...
  49.  
  50. Reasons that come to my mind for having "urn:" (I don't claim that anybody
  51. else needs to agree with these...):
  52.  
  53. 1. URNs are NOT URLs.
  54.  
  55. 2.  As a corollary to #1, using the same space for URN NIDs and URL
  56. schemes leads to greater collisions than keeping the spaces separate.  
  57. For example, I can see a collision occurring between the "cid:" URL scheme
  58. and a namespace of resources set up by some criminal investigation division
  59. (The fact that there are multiple CID organizations in the US attached to
  60. various police departments is an issue for the URN NID space
  61. by itself).  Keeping these two spaces separate allows each to
  62. deal with its own collisions and not worry about the other space.
  63.  
  64. 3. Currently (based on my interpretation of URL schemes, your mileage may
  65. vary), each and every URL scheme has a "resolution" "protocol" tied to it.
  66. The URN working group is proposing that initially there be a set of "resolution"
  67. "protocol(s)" for URNs tending toward a single resolution protocol.  All
  68. of these are independent of the URN NID.  Using
  69. "urn:" at the beginning of the URN provides a syntactic handle for 
  70. browsers to recognize URNs as being distinct from URLs.
  71.  
  72. 3a. (#3 has the result that URN-aware browsers do not have to be
  73. modified if a new NID is defined as compared to what is required for
  74. supporting a new URL scheme.  An addition to the "family" of resolution
  75. protocols for URNs would require browser modification , but the direction
  76. is for less URN resolution protocols rather than more).
  77.  
  78. Ryan Moats
  79.  
  80.  
  81.  
  82.  
  83.